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Abstract 


This document defines an RTP Control Protocol (RTCP) Extended Report 
(XR) Block including two new segment types and associated Session 
Description Protocol (SDP) parameters that allow the reporting of 
mean opinion score (MOS) Metrics for use in a range of RTP 
applications. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7266. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 

(http: //trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 
1.1. MOS Metrics Report Block 


This document defines a new block type to augment those defined in 
[RFC3611], for use in a range of RTP applications. 


The new block type provides information on media quality using one of 
several standard metrics (e.g., mean opinion score (MOS)). 


The metrics belong to the class of application-level metrics defined 
in [RFC6792]. 


1.2. RTCP and RTCP XR Reports 


The use of RICP for reporting is defined in [RFC3550]. RFC 3611 
defined an extensible structure for reporting using an RICP Extended 
Report (XR). This document defines a new Extended Report block for 
use with [RFC3550] and [RFC3611]. 


1.3. Performance Metrics Framework 


The Performance Metrics Framework [RFC6390] provides guidance on the 
definition and specification of performance metrics. The RTP 
Monitoring Architectures document [RFC6792] provides guidelines for 
reporting block format using RTCP XR. The XR block type described in 
this document is in accordance with the guidelines in [RFC6390] and 
[RFC6792]. 


1.4. Applicability 


The MOS Metrics Report Block can be used in any application of RTP 
for which OoE (Quality-of-Experience) measurement algorithms are 
defined. 


The factors that affect real-time audio/video application quality can 
be split into two categories. The first category consists of 
transport-specific factors such as packet loss, delay, and jitter 
(which also translates into losses in the playback buffer). The 
factors in the second category consists of content- and codec-related 
factors such as codec type and loss recovery technique, coding bit 
rate, packetization scheme, and content characteristics 


Transport-specific factors may be insufficient to infer real-time 
media quality as codec related parameters and the interaction between 
transport problems and application-layer protocols can have a 
substantial effect on observed media quality. Media quality may be 
measured using algorithms that directly compare input and output 
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media streams, or it may be estimated using algorithms that model the 
interaction between media quality, protocol, and encoded content. 
Media quality is commonly expressed in terms of MOS; however, it is 
also represented by a range of indexes and other scores. 


The measurement of media quality has a number of applications: 


o Detecting problems with media delivery or encoding that is 
impacting user-perceived quality. 


o Tuning the content encoder algorithm to satisfy real-time data 
quality requirements. 


o Determining which system techniques to use in a given situation 
and when to switch from one technique to another as system 
parameters change (for example, as discussed in [G.1082]). 


o Prequalifying a network to assess its ability to deliver an 
acceptable end-user-perceived quality level. 


2. Terminology 
2.1. Standards Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Notable terminology used is the following. 
Numeric formats X:Y 


where X the number of bits prior to the decimal place and Y the 
number of bits after the decimal place. 


Hence, 8:8 represents an unsigned number in the range 0.0 to 
255.996 with a granularity of 0.0039. 0:16 represents a proper 
binary fraction with range 0.0 to 1 - 1/65536 = 0.9999847, 
though note that use of flag values at the top of the numeric 
range slightly reduces this upper limit. For example, if the 
16-bit values OXFFFE and OXFFFF are used as flags for "over- 
range" and "unavailable" conditions, a 0:16 quantity has range 
0.0 to 1 - 3/65536 = 0.9999542. 


Calculation Algorithm 


Calculation Algorithm is used in this document to mean the MOS 
or QoE estimation algorithm. 
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3% 


MOS Metrics Block 


A multimedia application MOS Metric is commonly expressed as a MOS. 
The MOS is usually on a scale from 1 to 5, in which 5 represents 
excellent and 1 represents unacceptable; however, it can use other 


ranges (for example, 0 to 10 ). The term "MOS" originates from 
subjective testing and is used to refer to the mean of a number of 
individual opinion scores. Therefore, there is a well-understood 


relationship between MOS and user experience; hence, the industry 
commonly uses MOS as the scale for objective test results. 

Subjective tests can be used for measuring live network traffic; 
however, the use of objective or algorithmic measurement techniques 
allows much larger scale measurements to be made. Within the scope 
of this document, mean opinion scores are obtained using objective or 
estimation algorithms. ITU-T or ITU-R recommendations (e.g., 
[BS.1387-1], [G.107], [G.107.1], [P.862], [P.862.1], [P.862.2], 
[P.863], [P.564], [G.1082], [P.1201.1], [P.1201.2], [P.1202.1], 
[P.1202.2]) define methodologies for assessment of the performance of 
audio and video streams. Other international and national standards 
organizations such as EBU, ETSI, IEC, and IEEE also define QoE 
algorithms and methodologies, and the intent of this document is not 
to restrict its use to ITU recommendations but to suggest that ITU 
recommendations be used where they are defined. 


This block reports the media quality in the form of a MOS range 
(e.9., 1-5, 0-10, or 0-100, as specified by the calculation 
algorithm); however, it does not report the MOS that includes 
parameters outside the scope of the RTP stream, for example, 
signaling performance, mean time to repair (MITR), or other factors 
that may affect the overall user experience. 


The MOS Metric reported in this block gives a numerical indication of 
the perceived quality of the received media stream, which is 
typically measured at the receiving end of the RTP stream. Instances 
of this Metrics Block refer by synchronization source (SSRC) to the 
separate auxiliary Measurement Information block [RFC6776] which 
describes measurement periods in use (see RFC 6776, Section 4.2). 


This Metrics Block relies on the measurement period in the 
Measurement Information block indicating the span of the report. 
Senders MUST send this block in the same compound RTCP packet as the 
Measurement Information block. Receivers MUST verify that the 
measurement period is received in the same compound RTCP packet as 
this Metrics Block. If not, this Metrics Block MUST be discarded. 


Clark, et al. Standards Track [Page 5] 


REC 7266 


ds Ls 


RTCP XR MOS Report Blocks June 2014 


Report Block Structure 


The MOS Metrics Block has the following format: 


0 


1 2 3 


042345369789 01234567890 123456 7°89 01 


+-+-+-+-+-+-+-+-+-+- 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
| BT=29 | I | Reserved | Block Length 
+ 


+-+-+-+-+-+-+-+-+-+- 


+-+-+-+ 


+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
SSRC of source | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Segment 1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Segment 2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+ 


dd dh + + q + + q d+ + + +-+ 
Segment n 


EA A A A A A A A A A A A A A A A A A dd dd o + +4 


Definition of Fields in MOS Metrics Block 


Block type 


(BT): 8 bits 


The MOS Metrics Block is identified by the constant 29. 


Interval Metric flag (1): 2 bits 


Clark, 


This field is used to indicate whether the MOS Metrics are 
Sampled, 


Interval, or Cumulative [RFC6792]: 


Interval Duration - the reported value applies to the 
most recent measurement interval duration between 
successive metrics reports. 


Cumulative Duration - the reported value applies to the 
accumulation period characteristic of cumulative 


measurements. 


Sampled Value - the reported value is a sampled 
instantaneous value. 


Reserved 


In this document, MOS Metrics MAY be reported for intervals or for 
the duration of the media stream (cumulative). The value I=01, 
indicating a sampled value, MUST NOT be sent and MUST be discarded 
when received. 


et al. 
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Ts 


Reserved: 6 bits 


This field is reserved for future definition. In the absence of 
such a definition, the bits in this field MUST be set to zero and 
ignored by the receiver (see RFC 6709, Section 4.2). 


Block Length: 16 bits 


The length of this report block in 32-bit words, minus one. For 
the MOS Metrics Block, the block length is variable length. 


SSRC of source: 32 bits 
As defined in Section 4.1 of [RFC3611]. 
Segment i: 32 bits 


There are two segment types defined in this document: single- 
channel audio/video per SSRC segment and multi-channel audio per 
SSRC segment. Multi-channel audio per SSRC segment is used to 
deal with the case where multi-channel audio streams are carried 
in one RTP stream while a single-channel audio/video per SSRC 
segment is used to deal with the case where each media stream is 
identified by SSRC and sent in separate RTP streams. The leftmost 
bit of the segment determines its type. If the leftmost bit of 
the segment is zero, then it is a single-channel segment. If the 
leftmost bit is one, then it is a multi-channel audio segment. 
Note that two segment types cannot be present in the same metric 
block. 


1. Single-Channel Audio/Video per SSRC Segment 


+-+4-4- 4-4 4-4 44-44-4444 dd 4 4 4 4 4 + + + ++ +++ +++ 
|s] CAID | PT | MOS Value 
+ hh 4-4 4-4 de de e de dd dd dd 4 4 4 4 4 + + + +++ ++ +++ 


Segment Type (S): 1 bit 


This field is used to identify the segment type used in this 
report block. A zero identifies this as a single-channel 
audio/video per SSRC segment. Single channel means there is only 
one media stream carried in one RTP stream. The single-channel 
audio/video per SSRC segment can be used to report the MOS value 
associated with the media stream identified by SSRC. If there are 
multiple media streams and they want to use the single-channel 
audio/video per SSRC segment to report the MOS value, they should 
be carried in the separate RIP streams with each identified by 
different SSRC. In this case, multiple MOS Metrics Blocks are 
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required to report the MOS value corresponding to each media 
stream using single-channel audio/video per SSRC segment in the 
same RTCP XR packet. 


culation Algorithm ID (CAID) : 8 bits 


The 8-bit CAID is the session specific reference to the 
calculation algorithm and associated qualifiers indicated in SDP 
(see Section 4.1) and used to compute the MOS score for this 
segment. 


load Type (PT): 7 bits 


MOS Metrics reporting depends on the payload format in use. This 
field identifies the RTP payload type in use during the reporting 
interval. The binding between RTP payload types and RTP payload 
formats is configured via a signaling protocol, for example, an 
SDP offer/answer exchange. If the RTP payload type used is 
changed during an RIP session, separate reports SHOULD be sent for 
each RTP payload type, with corresponding measurement information 
blocks indicating the time period to which they relate. 


Note that the use of this Report Block with MPEG Transport streams 
carried over RTP is undefined as each MPEG Transport stream may 
use distinct audio or video codecs and the indication of the 
encoding of these is within the MPEG Transport stream and does not 
use RTP payloads. 


MOS Value: 16 bits 


Clark, 


The estimated mean opinion score (MOS) for multimedia application 
performance is estimated using an algorithm that includes the 
impact of delay, loss, jitter and other impairments that affect 
media quality. This is an unsigned fixed-point 7:9 value 
representing the MOS, allowing the MOS score up to 127 in the 
integer part. MOS ranges are defined as part of the specification 
of the MOS estimation algorithm (Calculation Algorithm in this 
document), and are normally ranges like 1-5, 0-10, or 0-100. Two 
values are reserved: a value of OxFFFE indicates that the 
measurement is out of range and a value of OxFFFF indicates that 
the measurement is unavailable. Values outside of the range 
defined by the Calculation Algorithm, other than the two reserved 
values, MUST NOT be sent and MUST be ignored by the receiving 
system. 
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3.2.2. Multi-Channel Audio per SSRC Segment 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|s] CAID | PT |CHID | MOS Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Segment Type (S): 1 bit 


This field is used to identify the segment type used in this 
report block. A one identifies this as a multi-channel audio 
segment. 


Calculation Algorithm ID (CAID) : 8 bits 


The 8-bit CAID is the session specific reference to the 
calculation algorithm and associated qualifiers indicated in SDP 
(see Section 4.1) and used to compute the MOS score for this 
segment. 


Payload Type (PT): 7 bits 
As defined in Section 3.2.1 of this document 
Channel Identifier (CHID): 3 bits 


If multiple channels of audio are carried in one RIP stream, each 
channel of audio will be viewed as an independent channel (e.g., 
left channel audio, right channel audio). This field is used to 
identify each channel carried in the same media stream. The 
default channel mapping follows static ordering rule described in 
Section 4.1 of [RFC3551]. However, there are some payload formats 
that use different channel mappings, e.g., AC-3 audio over RTP 
[RFC4184] only follow AC-3 channel order scheme defined in [ATSC]. 
Enhanced AC-3 audio over RTP [RFC4598] uses a dynamic channel 
transform mechanism. In order for the appropriate channel mapping 
to be determined, MOS metrics reports need to be tied to an RTP 
payload format. The reports should include the payload type of 
the reported media according to [RFC6792], so that it can be used 
to determine the appropriate channel mapping. 


MOS Value: 13 bits 


The estimated MOS for multimedia application performance is 
defined as including the effects of delay, loss, discard, jitter 
and other effects that would affect media quality. This is an 
unsigned fixed-point 7:6 value representing the MOS, allowing the 
MOS score up to 127 in the integer part. MOS ranges are defined 
as part of the specification of the MOS estimation algorithm 
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(Calculation Algorithm in this document), and are normally ranges 
like 1-5, 0-10, or 0-100. Two values are reserved: a value of 
Ox1FFE indicates out of range and a value of 0x1FFF indicates that 
the measurement is unavailable. Values outside of the range 
defined by the Calculation Algorithm, other than the two reserved 
values, MUST NOT be sent and MUST be ignored by the receiving 


system. 


4. SDP Signaling 


[RFC3611] defines the use of SDP [RFC4566] for signaling the use of 
XR blocks. However, XR blocks MAY be used without prior signaling 
(see Section 5 of RFC 3611). 


4.1. SDP "rtcp-xr-attrib" Attribute Extension 


This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 
in [RFC3611] by providing an additional value of "xr-format" to 
signal the use of the report block defined in this document. Within 
the "xr-format", the syntax element "calgextmap" is an attribute as 
defined in [RFC4566] and used to signal the mapping of the local 
identifier (CAID) in the segment extension defined in Section 3.2 to 
the calculation algorithm. Specific extension attributes are defined 
by the specification that defines a specific extension name: there 
might be several. The ABNF [RFC5234] syntax is as follows. 
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xr-format =/ xr-mos-block 


xr-mos-block = "mos-metric" ["=" calgextmap *("," calgextmap) ] 
calgextmap = mapentry "=" extensionname [SP extentionattributes] 
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 
mapentry = "calg:" 1*3DIGIT [ "/" direction ] 


; Values in the range 1-255 are valid 
; if needed, 0 can be used to indicate that 
; an algorithm is rejected 
= "P564";ITU-T P.564 Compliant Algorithm [P.564] 
/ "G107";ITU-T G.107 [G.107] 
/ "G107_1";ITU-T G.107.1 [G.107.1] 
/ "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI] 
/"33201_1 "¿TIC JJ201.1 [TTC] 
/"P1201_1";ITU-T P.1201.2 [P.1201.1] 
/"P1201_2";ITU-T P.1201.2 [P.1201.2] 
/"P1202_1";ITU-T P.1202.1 [P.1202.1] 
/"P1202_2";1TU-T P.1202.2 [P.1202.2] 
/"P.862.2";1TU-T P.862.2 [P.862.2] 
/"P.863"; ITU-T P.863 [P.863] 
/ non-ws-string 


extensionname 


tu tu tu I 


extensionattributes = mosref 
/attributes-ext 
mosref = "mosref=" ("1"; lower resolution 


/"m"; middle resolution 
/ "h";higher resolution 
/ non-ws-string) 


attributes-ext = non-ws-string 
SP = <Defined in RFC 5234> 
non-ws-string = 1*(%x21-FF) 


Bach local identifier (CAID) of calculation algorithm used in the 
segment defined in Section 3.2 is mapped to a string using an 
attribute of the form: 


a=calg:<value> [ "/"<direction> ] <name> [<extensionattributes>] 


where <name> is a calculation algorithm name, as above, <value> is 
the local identifier (CAID) of the calculation algorithm associated 
with the segment defined in this document and is an integer in the 
valid range, inclusive. 


Example: 
a=rtcp-xr:mos-metric=calg:1=G107,calg:2=P1202_1 


A usable mapping MUST use IDs in the valid range, and each ID in this 


range MUST be unique and used only once for each stream or each 
channel in the stream. 
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The mapping MUST be provided per media stream (in the media-level 
section(s) of SDP, i.e., after an "m=" line). 


The syntax element "mosref" is referred to the media resolution 
relative reference and has three values '1','m','h'. (e.g., 
narrowband (3.4 kHz) speech and Standard Definition (SD) or lower 
resolution video have '1' resolution, super-wideband (>14 kHz) speech 
or higher and High Definition (HD) or higher resolution video have 
’h’ resolution, wideband speech (7 kHz) and video with resolution 
between SD and HD has 'm” resolution). The MOS reported in the MOS 
metrics block might vary with the MOS reference; for example, MOS 
values for narrowband, wideband, super-wideband codecs occupy the 
same range but SHOULD be reported in different value. For video 
application, MOS scores for SD resolution, HD resolution video also 
occupy the same ranges and SHOULD be reported in different value. 


4.2. Offer/Answer Usage 


When SDP is used in offer/answer context, the SDP Offer/Answer usage 
defined in [RFC3611] applies. In the offer/answer context, the 
signaling described above might be used in three ways: 


o asymmetric behavior (segment extensions sent in only one 
direction), 


o the offer of mutually exclusive alternatives, or 
o the offer of more segments than can be sent in a single session. 


A direction attribute MAY be included in a "calgextmap"; without it, 
the direction implicitly inherits, of course, from the RTCP stream 
direction. 


Segment extensions, with their directions, MAY be signaled for an 
"inactive" stream. An extension direction MUST be compatible with 
the stream direction. If a segment extension in the SDP offer is 
marked as "sendonly" and the answerer desires to receive it, the 
extension MUST be marked as "recvonly" in the SDP answer. An 
answerer that has no desire to receive the extension or does not 
understand the extension SHOULD NOT include it in the SDP answer. 


If a segment extension is marked as "recvonly" in the SDP offer and 
the answerer desires to send it, the extension MUST be marked as 
"sendonly" in the SDP answer. An answerer that has no desire to, or 
is unable to, send the extension SHOULD NOT include it in the SDP 
answer. 
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If a segment extension is offered as "sendrecv", explicitly or 
implicitly, and asymmetric behavior is desired, the SDP MAY be 
modified to modify or add direction qualifiers for that segment 
extension. 


A "mosref" attribute and "MOS Type" attribute MAY be included in a 
calgextmap; if not present, the "mosref" and "MOS Type" MUST be as 
defined in the OoE estimation algorithm referenced by the name 
attribute (e.g., P.1201.1 [P.1201.1] indicates lower resolution used 
while P.1201.2 [P.1201.2] indicates higher resolution used) or 
payload type carried in the segment extension (e.g., EVRC-WB 
[RFC5188] indicates using Wideband Codec). However, not all payload 
types or MOS algorithm names indicate resolution to be used and MOS 
type to be used. If an answerer receives an offer with a "mosref" 
attribute value it doesn't support (e.g.,the answerer only supports 
"1" and receives "h" from offerer), the answer SHOULD reject the 
mosref attribute value offered by the offerer. 


If the answerer wishes to reject a "mosref" attribute offered by the 
offerer, it sets identifiers associated with segment extensions in 


the answer to the value in the range 4096-4351. The rejected answer 
MUST contain a "mosref" attribute whose value is the value of the SDP 
offer. 


Local identifiers in the valid range (inclusive) in an offer or 
answer must not be used more than once per media section. A session 
update MAY change the direction qualifiers of segment extensions 
under use. A session update MAY add or remove segment extension (s). 
Identifier values in the valid range MUST NOT be altered (remapped). 


If a party wishes to offer mutually exclusive alternatives, then 
multiple segment extensions with the same identifier in the 
(unusable) range 4096-4351 MAY be offered; the answerer SHOULD select 
at most one of the offered extensions with the same identifier, and 
remap it to a free identifier in the valid range for that extension 
to be usable. Note that the two segment types defined in Section 3 
are also exclusive alternatives. 


If more segment extensions are offered in the valid range, the 
answerer SHOULD choose those that are desired and place the offered 
identifier value "as is" in the SDP answer. 


Similarly, if more segment extensions are offered than can be fit in 
the valid range, identifiers in the range 4096-4351 MAY be offered; 
the answerer SHOULD choose those that are desired and remap them to a 
free identifier in the valid range. 
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Note that the range 4096-4351 for these negotiation identifiers is 
deliberately restricted to allow expansion of the range of valid 
identifiers in the future. Segment extensions with an identifier 
outside the valid range cannot, of course, be used. 


Example: 


Note - port numbers, RIP profiles, payload IDs and rtpmaps, etc., 
have all been omitted for brevity. 


The offer: 


a=rtcp-xr:mos-metric=calg:4906=P1201_1,calg:4906=P1202_1, calg: 
4907=G107 


The answerer is interested in transmission P.1202.1 on a lower 
resolution application, but it doesn't support P.1201.1 on a lower 
resolution application at all. It is interested in transmission 
G.107. Therefore, it adjusts the declarations: 


a=rtcp-xr:mos-metric=calg:1=P1202_1,calg:2=G107 

5. IANA Considerations 
New block types for RTCP XR are subject to IANA registration. For 
general guidelines on IANA considerations for RTCP XR, refer to 
[RFC3611]. 

5.1. New RTCP XR Block Type Value 
This document assigns the block type value 29 in the IANA "RTP 
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 
the "MOS Metrics Block". 

5.2. New RTCP XR SDP Parameter 
This document also registers a new parameter "mos-metric" in the "RTP 


Control Protocol Extended Reports (RTCP XR) Session Description 
Protocol (SDP) Parameters Registry". 


5.3. The SDP "calgextmap" Attribute 


This section contains the information required by [RFC4566] for an 
SDP attribute. 


o contact name, email address: RAI Area Directors 
<rai-ads@tools.ietf.org> 
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o attribute name (as it will appear in SDP): calgextmap 


o long-form attribute name in English: calculation algorithm map 
definition 


o type of attribute (session level, media level, or both): both 


o whether the attribute value is subject to the charset attribute: 
not subject to the charset attribute 


o a one-paragraph explanation of the purpose of the attribute: This 
attribute defines the mapping from the local identifier (CAID) in 
the segment extension defined in Section 3.2 into the calculation 
algorithm name as documented in specifications and appropriately 
registered. 


o a specification of appropriate attribute values for this 
attribute: see RFC 7266. 


5.4. New Registry of Calculation Algorithms 


This document creates a new registry called "RTCP XR MOS Metric block 
- multimedia application Calculation Algorithm" as a subregistry of 
the "RTP Control Protocol Extended Reports (RTCP XR) Block Type 
Registry". This registry applies to the multimedia session where 
each type of medium is sent in a separate RTP stream and also applies 
to the session where multi-channel audios are carried in one RTP 
stream. Policies for this new registry are as follows: 


o The information required to support this assignment is an 
unambiguous definition of the new metric, covering the base 
measurements and how they are processed to generate the reported 


metric. 


o The review process for the registry is "Specification Required" as 
described in Section 4.1 of [RFC5226]. 


o Entries in the registry are identified by entry name and mapped to 
the local identifier (CAID) in the segment extension defined in 
Section 3.2. 

o Registration Template 


The following information must be provided with each registration: 


* Name: A string uniquely and unambiguously identifying the 
calculation algorithm for use in protocols. 
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* Name Description: A valid Description of the calculation 
algorithm Name. 


* Reference: 


corresponding to the Name and Name Description. 


* Types 


The reference that defines the calculation algorithm 


The media type to which the calculation algorithm is 
applied 


o Initial assignments are as follows: 


Name Name Description Reference Type 
P564 ITU-T P.564 Compliant Algorithm [P.564] voice 
G107 ITU-T G.107 [G.107] voice 
TS101_329 ETSI TS 101 329-5 Annex E [ETSI] voice 
JJ201_1 TTC JJ201.1 [TTC] voice 
G107_1 ITU-T G.107.1 [G.107.1] voice 
P862 ITU-T P.862 [P.862] voice 
P862_2 ITU-T P.862.2 [P.862.2] voice 
P863 ITU-T P.863 [P.863] voice 
P1201_1 TITUST PL 1201,72 [P.1201.1] multimedia 
P1201_2 ITU-T P.1201.2 [P.1201.2] multimedia 
P1202_1 ITU-T P.1202.1 [P.1202.1] video 
P1202_2 ITU-T P.1202.2 [P.1202.2] video 
6. Security Considerations 


The new RTCP XR blocks proposed in this document introduce no new 
security considerations beyond those described in [RFC3611]. 
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Appendix A. Metrics Represented Using the Template from RFC 6390 
a. MOS Value Metric 
* Metric Name: MOS in RTP 
* Metric Description: The estimated mean opinion score for 
multimedia application performance of the RTP stream is defined 
as including the effects of delay, loss, discard, jitter, and 


others on audio or video quality. 


* Method of Measurement or Calculation: See Section 3.2.1, MOS 
value definition. 


* Units of Measurement: See Section 3.2.1, MOS value definition. 


* Measurement Point (s) with Potential Measurement Domain: See 
Section 3, second paragraph. 


* Measurement Timing: See Section 3, third paragraph for 
measurement timing and Section 3.1 for Interval Metric flag. 


* Use and applications: See Section 1.4. 
* Reporting model: See RFC 3611. 
b. Segment Type Metric 
* Metric Name: Segment Type in RTP 
* Metric Description: It is used to identify the segment type of 
RTP stream used in this report block. For more details, see 


Section 3.2.1, Segment type definition. 


* Method of Measurement or Calculation: See Section 3.2.1, 
Segment Type definition. 


* Units of Measurement: See Section 3.2.1, Segment Type 
definition. 


* Measurement Point (s) with Potential Measurement Domain: See 
Section 3, second paragraph. 


* Measurement Timing: See Section 3, third paragraph for 
measurement timing and Section 3.1 for Interval Metric flag. 


* Use and applications: See Section 1.4. 
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* Reporting model: See RFC 3611. 
c. Calculation Algorithm Identifier Metric 
* Metric Name: RTP Stream Calculation Algorithm Identifier 
* Metric Description: It is the local identifier of RTP Stream 
calculation Algorithm associated with this segment in the range 


1-255 (inclusive). 


* Method of Measurement or Calculation: See Section 3.2.1, 
Calculation Algorithm ID definition. 


* Units of Measurement: See Section 3.2.1, Calg Algorithm ID 
definition. 


* Measurement Point(s) with Potential Measurement Domain: See 
Section 3, second paragraph. 


* Measurement Timing: See Section 3, third paragraph for 
measurement timing and Section 3.1 for Interval Metric flag. 


* Use and applications: See Section 1.4. 
* Reporting model: See RFC 3611. 
d. Payload Type Metric 
* Metric Name: RTP Payload Type 
* Metric Description: It is used to identify the format of the 
RTP payload. For more details, see Section 3.2.1, payload type 


definition. 


* Method of Measurement or Calculation: See Section 3.2.1, 
Payload type definition. 


* Units of Measurement: See Section 3.2.1, Payload type 
definition. 


* Measurement Point(s) with Potential Measurement Domain: See 
Section 3, second paragraph. 


* Measurement Timing: See Section 3, third paragraph for 
measurement timing and Section 3.1 for Interval Metric flag. 


* Use and applications: See Section 1.4. 
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Reporting model: See RFC 3611. 


Channel Identifier Metric 


Metric Name: Audio Channel Identifier in RTP 


Metric Description: It is used to identify each audio channel 
carried in the same RTP stream. For more details, see Section 
3.2.2, channel identifier definition. 


Method of Measurement or Calculation: See Section 3.2.2, 
Channel Identifier definition. 


Units of Measurement: See Section 3.2.2, Channel Identifier 
definition. 


Measurement Point (s) with Potential Measurement Domain: See 
Section 3, second paragraph. 


Measurement Timing: See Section 3, third paragraph for 
measurement timing and Section 3.1 for Interval Metric flag. 


Use and applications: See Section 1.4. 


Reporting model: See RFC 3611. 
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